Populating resource-constrained devices with content verified using API definitions

ABSTRACT

A method for remote incremental program verification includes receiving content verified by at least one content provider, installing the content on a resource-constrained device and issuing the resource-constrained device to an end user. The content includes at least one program unit and each program unit includes an Application Programming Interface (API) definition file and an implementation. Each API definition file defines items in its associated program unit that are made accessible to one or more other program units and each implementation includes executable code corresponding to the API definition file. The executable code includes type specific instructions and data. According to one aspect, subsequent installation of content on the resource-constrained device is disabled. A resource-constrained device includes a memory for providing content verified by at least one content provider and a virtual machine that is capable of executing instructions included within the content. The content includes at least one program unit and each program unit includes an Application Programming Interface (API) definition file and an implementation. Each API definition file defines items in its associated program unit that are made accessible to one or more other program units, each implementation includes executable code corresponding to the API definition file, and executable code includes type specific instructions and data.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional patent applicationSer. No. 60/200,480 filed Apr. 28, 2000 in the name of Judith E.Schwabe, entitled “System and Method for Remote Incremental ProgramVerification Using API Definitions”.

This application is related to the following:

U.S. patent application filed Sep. 14, 2000 in the name of inventorJudith E. Schwabe, entitled “Remote Incremental Program VerificationUsing API Definitions”, Attorney Docket No. SUN-P4172, commonly assignedherewith.

U.S. patent application filed Sep. 14, 2000 in the name of inventorJudith E. Schwabe, entitled “Remote Incremental Program BinaryCompatibility Verification Using API Definitions”, Attorney Docket No.SUN-P4174, commonly assigned herewith.

U.S. patent application filed Sep. 14, 2000 in the name of inventorJudith E. Schwabe, entitled “Populating Binary CompatibleResource-Constrained Devices With Content Verified Using APIDefinitions”, Attorney Docket No. SUN-P4182, commonly assigned herewith.

U.S. patent application filed Sep. 14, 2000 in the name of inventorJudith E. Schwabe, entitled “API Representation Enabling SubmergedHierarchy”, Attorney Docket No. SUN-P4175, commonly assigned herewith.

U.S. patent application Ser. No. 09/243,108 filed Feb. 2, 1999 in thename of inventors Judith E. Schwabe and Joshua B. Susser, entitled“Token-based Linking”.

FIELD OF THE INVENTION

The present invention relates to computer systems. More particularly,the present invention relates to a system and method for remotedistributed program verification using API definitions.

BACKGROUND

In general, computer programs are written as source code statements in ahigh level language that is easy for a human being to understand. As thecomputer programs are actually executed, a computer responds to machinecode, which consists of instructions comprised of binary signals thatdirectly control the operation of a central processing unit (CPU). Aspecial program called a compiler is typically used to read the sourcecode and to convert its statements into the machine code instructions ofthe specific CPU. The machine code instructions thus produced areplatform dependent, that is, different computer devices have differentCPUs with different instruction sets indicated by different machinecodes.

More powerful programs are typically constructed by combining severalsimpler programs. This combination can be made by copying segments ofsource code together before compiling and then compiling the combinedsource. When a segment of source code statements is frequently usedwithout changes, it is often preferable to compile it once, by itself,to produce a module, and to combine the module with other modules onlywhen that functionality is actually needed. This combining of modulesafter compilation is called linking. When the decision on which modulesto combine depends upon run time conditions and the combination of themodules happens at run time, just before execution, the linking iscalled dynamic linking.

Object Oriented Principles

Object oriented programming techniques such as those used by the Java™platform are widely used. The basic unit of object oriented programs isan “object”. An object has methods (procedures) and fields (data). Theterm “members” is used herein to refer to methods and fields. A methoddeclares executable code that can be invoked and that passes a fixednumber of values as arguments. A class defines the shared members of theobjects. Each object then is a particular instance of the class to whichit belongs. In practice, a class is a template to create multipleobjects (multiple instances) with similar features.

One property of classes is encapsulation. Encapsulation is used todescribe a system wherein access to an object is provided through aninterface, while keeping the details private. In other words, the actualimplementation of the members Within the class is hidden from an outsideuser and from other classes, except as exposed by an interface. Thismakes classes suitable for distributed development, for example bydifferent developers at different sites on a network. A complete programcan be formed by assembling the classes that are needed, linking themtogether, and executing the resulting program.

Classes enjoy the property of inheritance. Inheritance is a mechanismthat enables one class to inherit all of the members of another class.The class that inherits from another class is called a subclass; theclass that provides the attributes is the superclass. Symbolically, thiscan be written as subclass<=superclass, or superclass=>subclass. Thesubclass can extend the capabilities of the superclass by addingadditional members. The subclass can override a virtual method of thesuperclass by providing a substitute method with the same name and type.

The members of a class type are fields and methods; these includemembers inherited from the superclass. The class file also names thesuperclass. A member can be public, which means that it can be accessedby members of the class that contains its declaration. A member can alsobe private. A private field of a class is visible only in methodsdefined within that class. Similarly, a private method may only beinvoked by methods within the class. Private members are not visiblewithin subclasses, and are not inherited by subclasses as other membersare. A member can also be protected.

An interface type is a type whose members are constants and abstractmethods. This type has no implementation, but otherwise unrelatedclasses can implement it by providing implementations for its abstractmethods. Interfaces may have sub-interfaces, just as classes may havesubclasses. A sub-interface inherits from its super-interface, and maydefine new methods and constants as well. Additionally, an interface canextend more than one interface at a time. An interface that extends morethan one interface inherits all the abstract methods and constants fromeach of those interfaces, and may define its own additional methods andconstants.

Java™ Programming Language

In the Java™ programming language, classes can be grouped and the groupcan be named; the named group of classes is a package. If a class memberis not declared with any of the public, private or protected keywords,then it is visible only within the class that defines it and withinclasses that are part of the same package. A protected member may beaccessed by members of declaring class or from anywhere in the packagein which it is declared. The Java™ programming language is described indetail in Gosling, et al., “The Java™ Language Specification”, August1996, Addison-Wesley Longman, Inc.

Java™ Virtual Machine

Programs written in the Java™ language execute on a Java™ virtualmachine (JVM), which is an abstract computer architecture that can beimplemented in hardware or software. Either implementation is intendedto be included in the following description of a VM. For the purposes ofthis disclosure, the term “processor” may be used to refer to a physicalcomputer or a virtual machine.

A virtual machine is an abstract computing machine generated by asoftware application or sequence of instructions that is executed by aprocessor. The term “architecture-neutral” refers to programs, such asthose written in the Java programming language, which can be executed bya virtual machine on a variety of computer platforms having a variety ofdifferent computer architectures. Thus, for example, a virtual machineimplemented on a Windows™-based personal computer system will execute anapplication using the same set of instructions as a virtual machineimplemented on a UNIX™-based computer system. The result of theplatform-independent coding of a virtual machine's sequence ofinstructions is a stream of one or more bytecodes, each of which is, forexample, a one-byte-long numerical code.

The Java™ Virtual Machine (JVM) is one example of a virtual machine.Compiled code to be executed by the Java™ Virtual Machine is representedusing a hardware- and operating system-independent binary format,typically stored in a file, known as the class file format. The classfile is designed to handle object oriented structures that can representprograms written in the Java™ programming language, but may also supportseveral other programming languages. These other languages may include,by way of example, Smalltalk. The class file format precisely definesthe representation of a class or interface, including details such asbyte ordering that might be taken for granted in a platform-specificobject file format. For the sake of security, the Java™ Virtual Machineimposes strong format and structural constraints on the instructions ina class file. In particular example, JVM instructions are type specific,intended to operate on operands that are of a given type as explainedbelow. Any language with functionality that can be expressed in terms ofa valid class file can be hosted by the Java™ Virtual Machine. The classfile is designed to handle object oriented structures that can representprograms written in the Java™ programming language, but may also supportseveral other programming languages. The Java™ Virtual Machine isdescribed in detail in Lindholm, et al., “The Java™ Virtual MachineSpecification”, April 1999, Addison-Wesley Longman, Inc., SecondEdition.

The process of programming using such a VM then has two time periodsassociated with it; “compile time” refers to the steps which convert thehigh level language into VM instructions, and “run time” refers to thesteps which, in a Java™ VM environment, interpret instructions toexecute the module. Between compile time and run time, the modules ofinstructions compiled from statements can reside dormant for extended,arbitrary periods of time, or can be transferred from one storage deviceto another, including being transferred across a network.

Loading refers to the process of finding the binary form of a class ormodule with a particular name, typically by retrieving a binaryrepresentation previously compiled from source code. In the JVM, theloading step retrieves the class file representing the desired class.The loading process is implemented by the bootstrap loader or a userdefined class loader. A user-defined class loader is itself defined by aclass. A class loader may indicate a particular sequence of locations tosearch in order to find the class file representing a named class.

Linking in the JVM is the process of taking a binary form of a class inmemory and combining it into the run time state of a VM, so that it canbe executed. A class is loaded before it is linked.

Verification

For many reasons, particularly regarding the integrity of downloadedcomputer programs, the Internet and other insecure communication mediumsare potentially “hostile” environments. A downloaded program may containerrors involving the data types of operands not matching the data typerestrictions of the instructions using those operands, which may causethe program to fail during execution. Even worse, a program mightattempt to create object references (e.g. by loading a computed numberinto the operand stack and then attempting to use the computed number asan object handle) and to thereby breach the security and/or integrity ofthe user's computer. Alternatively, one or more of the modules may havebeen updated since the others were prepared. It is therefore prudent,when assembling several modules that may have been writtenindependently, to check both that (1) each module properly adheres tothe language semantics and that (2) the set of modules properly adheresto the language semantics. These checks are typically performed onprogram modules containing instructions produced from compiled sourcecode. By analogy with the terminology used by the designers of the Java™programming language, this post-compilation module checking can becalled verification. A verifier, therefore, performs an essential rolein ensuring a secure runtime environment.

The binary classes of the JVM are examples of general program modulesthat contain instructions produced from compiled source statements.Context sensitivity of validity checks performed during verificationmeans that those checks depend on information spread across more thanone module, i.e., those checks are called inter-module checks herein.Validity checks that do not require information from another module arecalled intra-module checks herein. Intra-module checks include, forexample, determining whether the downloaded program will underflow oroverflow its stack, whether any instruction will process data of thewrong type and whether the downloaded program will violate files andother resources on the user's computer. See, for example, U.S. Pat. No.5,668,999 to Gosling, U.S. Pat. No. 5,748,964 to Gosling and U.S. Pat.No. 5,740,441 to Yellin et al.

During normal execution of programs using languages that do not featurepre-execution verification, the operand stack must be continuouslymonitored for overflows (i.e., adding more data to the stack than thestack can store) and underflows (i.e., attempting to pop data off thestack when the stack is empty). Such stack monitoring must normally beperformed for all instructions that change the stack's status (whichincludes most all instructions). For many programs, stack monitoringinstructions executed by the interpreter account for approximately 80%of the execution time of an interpreted computer program.

Turning now to FIG. 1, a high level flow diagram that illustratesverification is presented. At 10, intra-module checks are performed todetermine whether a module is internally consistent. At 20, inter-modulechecks are performed to determine whether the module is consistentwithin the context of externally referenced modules. Verification issuccessful if both checks pass. Execution of a module is prevented ifeither checks fail.

Verification typically follows an execution path. Verification starts ata program's main entry point and proceeds in a “top down” fashion, oneinstruction at a time. During this process, the verifier may encounter areference to an external library that includes at least one programunit. At this point, the verifier obtains the binary file for theexternal library and continues verification along an execution path.

Turning now to FIG. 2, a high level flow diagram that illustratesverification of an application to be executed on a resource-rich device62 is presented. Verification is typically performed on a relativelyresource-rich device 62 such as a desktop computer. A compiler 50compiles a source file 55. During compilation, the compiler 50 verifiesthe correct use of data and instructions. These checks includeintra-module checks and inter-module checks. The output of the sourcecode compiler 50 is a binary file 60 containing the executableinstructions corresponding to the source file 55. When the binary file60 is referenced by an application executing on a virtual machine 65, aloader 70 loads the binary file 60. A verifier 75 verifies the binaryfile 60 at some point prior to execution by an interpreter 80. If thebinary file 60 references any items that are external to the binary file60, the verifier 75 verifies the binary file 60 against the referencedbinary file(s) 60 containing the externally referenced item(s).

Turning now to FIG. 3, a block diagram that illustrates the need forverification is presented. FIG. 3 is the same as FIG. 2, except thatbinary file 110 and/or referenced binary file 107 are potentiallymodified at some point after source file 105 is compiled. Themodification may be the result of an update of a binary file 110 orreferenced binary file 107. Alternatively, modification of the binaryfile 110 or referenced binary file 107 may be the result of filecorruption. As mentioned previously, such program modifications couldpotentially cause the program to violate Java™ semantics and thus breachthe security and/or integrity of the host computer 155.

Note that some updates in FIG. 3 are allowed. Some changes made whenrevising a binary file result in the new version being backwardcompatible with the previous version. When a newer version is backwardcompatible with an older version, the versions are said to be binarycompatible. Binary compatibility is discussed in greater detail below. Averification error should be indicated when versions are not binarycompatible. Thus, some updates may pass verification, but corruptedbinary files must not pass verification.

Verification coupled with execution time has some disadvantages. Forexample, in an object oriented programming language system like theJava™ platforms (but not Java Card™ platforms), it leads to a verifierinitiating class loading when the verifier needs to check subtyperelations among classes not already loaded. Such loading can occur evenif the code referencing other classes is never executed. Because ofthis, loading can consume memory and slow execution at run time ascompared to a process that does not load the classes unless they arereferenced by the instructions that are actually executed.

Methods for verification coupled with execution time typically do notverify one class or module at a time before run time. This is adisadvantage because classes cannot be verified ahead of time, e.g.before run time, so verification must incur a run time cost. Thus, thereis a need for module-by module, also called module-at-a-time,verification before run time. Such verification is also calledpre-verification because technically it is distinct from theverification which occurs during run time linking by the Java Card™Virtual Machine (JCVM).

Also, since verification is typically performed at run time, a classthat has been run once, and passed verification, is subjected toverification again each time the class is loaded—even whenreverification is not required. Reverification may not be required, forexample, when the class is being used in the same application on thesame processor, or in an environment that prevents changes that wouldaffect verification. This can lead to redundant verification, therebyrequiring more memory and executing more slowly during run time thanought to be necessary. Thus, there is a need for an option to useverified modules without further, or with minimum verification at runtime.

Resource-Constrained Devices

Resource-constrained devices are generally considered to be those thatare relatively restricted in memory and/or computing power or speed, ascompared to typical desktop computers and the like. Otherresource-constrained devices include, by way of example, smart cards,cellular telephones, boundary scan devices, field programmable devices,personal digital assistants (PDAs) and pagers and other miniature orsmall footprint devices.

Smart cards, also known as intelligent portable data-carrying cards, area type of resource-constrained device. Smart cards are typically made ofplastic or metal and have an electronic chip that includes an embeddedmicroprocessor or microcontroller to execute programs and memory tostore programs and data. Such devices, which can be about the size of acredit card, typically have computer chips with 8-bit or 16-bitarchitectures. Additionally, these devices typically have limited memorycapacity. For example, some smart cards have less than one kilobyte (1K)of random access memory (RAM) as well as limited read only memory (ROM),and/or non-volatile memory such as electrically erasable programmableread only memory (EEPROM).

A Java™ virtual machine executes programs written in the Java™programming language and is designed for use on desktop computers, whichare relatively rich in memory. It would be desirable to write programsthat use the full implementation of the Java™ virtual machine forexecution on resource-constrained devices such as smart cards. However,due to the limited architecture and memory of resource-constraineddevices such as smart cards, the full Java™ virtual machine platformcannot be implemented on such devices. Accordingly, a separate JavaCard™ (the smart card that supports the Java™ programming language)technology supports a subset of the Java™ programming language forresource-constrained devices.

Referring to FIG. 4, development of an applet for a resource-constraineddevice, such as a smart card 160, begins in a manner similar todevelopment of a Java™ program. In other words, a developer writes oneor more Java™ classes and compiles the source code with a Java™ compilerto produce one or more class files 165. The applet can be run, testedand debugged, for example, on a workstation using simulation tools toemulate the environment on the card 160. When the applet is ready to bedownloaded to the card 160, the class files 165 are converted to aconverted applet (CAP) file 175 by a converter 180. The converter 180can be a Java™ application being executed by a desktop computer. Theconverter 180 can accept as its input one or more export files 185 inaddition to the class files 165 to be converted. An export file 185contains naming or linking information for the contents of otherpackages that are imported by the classes being converted.

Referring to FIG. 5, the CAP format is parallel to the class fileinformation. Each CAP 250 contains all of the classes and interfacesdefined in one Java™ package. A CAP file 250 has a compact and optimizedformat, so that a Java™ package can be efficiently stored and executedon resource-constrained devices. Among other things, the CAP file 250includes a constant pool component (or “constant pool”) 255 that ispackaged separately from a methods component 260. The constant pool 255can include various types of constants including method and fieldreferences which are resolved either when the program is linked ordownloaded to the smart card or at the time of execution by the smartcard. The methods component 260 specifies the application instructionsto be downloaded to the smart card and subsequently executed by thesmart card. Also included in a CAP file 250, among other things, areclass definitions 265, field definitions 275, and descriptive typedefinitions 275.

Referring again to FIG. 4, after conversion, the CAP file 175 can bestored on a computer-readable medium 170 such as a hard drive, a floppydisk, an optical storage medium, a flash device or some other suitablemedium. Or the computer-readable medium can be in the form of a carrierwave, e.g., a network data transmission or a radio frequency (RF) datalink.

The CAP file 175 then can be copied or transferred to a terminal 190such as a desktop computer with a peripheral card acceptance device(CAD) 195. The CAD 195 allows information to be written to and retrievedfrom the smart card 160. The CAD 195 includes a card port (not shown)into which the smart card 160 can be inserted. Once inserted, contactsfrom a connector press against the surface connection area on the smartcard 160 to provide power and to permit communications with the smartcard 160, although, in other implementations, contactless communicationscan be used. The terminal 190 also includes an installation tool 200that loads the CAP file 175 for transmission to the card 160.

The smart card 160 has an input/output (I/O) port 205 which can includea set of contacts through which programs, data and other communicationsare provided. The card 160 also includes a loader 210 for receiving thecontents of the CAP file 175 and preparing the applet for execution onthe card 160. The installation tool 210 can be implemented, for example,as a Java™ program and can be executed on the card 160. The card 160also has memory, including volatile memory such as RAM 240. The card 160also has ROM 230 and non-volatile memory, such as EEPROM 235. The appletprepared by the loader 210 can be stored in the EEPROM 235.

As mentioned regarding FIG. 2, verification is typically performed on aresource-rich device. Verification programs are typically large programsthat require a relatively large amount of runtime memory when executing.Also, verifier programs typically require large amounts of detaileddescriptive information in the verification process. This descriptiveinformation includes information regarding field types, signature typesand access flags (private, protected, etc). This type information istypically maintained in secondary storage. Such memory requirements aretypically not an issue on relatively resource rich devices such as adesktop computer. However, these same characteristics make verificationill-suited for resource-constrained devices such as smart cards.Providing verification of program modules to execute on aresource-constrained device is critical to ensure the integrity ofprogram modules executed such a device. Accordingly, a need exists inthe prior art for a system and method for remote verification ofprograms to be executed by a resource-constrained device.

As mentioned previously, a Java™ verifier proceeds along an applet'sexecution path, verifying all external references in the process. Thismeans that the verifier must have access to the full binary file of notonly the module to be verified, but also all modules in the executionpath of the module to be verified. However, some of the libraries maycontain proprietary implementations that must not be revealed toconsumers. For example, a vendor may install a library that containsproprietary implementation algorithms (such as an encryption algorithm)that must not be revealed to another vendor. Since typical verificationmethods require revealing the binary files of the modules to beverified, such methods could reveal proprietary information.Accordingly, there is a need in the prior art for a system and methodfor program verification that does not reveal proprietary details.

Moreover, a library may have multiple implementations. Verification witha particular implementation does not guarantee verification with anotherimplementation. Accordingly, there is a need in the prior art for asystem and method for specifying when verification with a firstimplementation guarantees verification with a second implementation.

Program Module Hierarchical Dependencies

FIG. 6 shows a diagram illustrating typical hierarchical dependenciesamong a group of program packages (including both libraries and programapplets) loaded onto a smart card. Applications may be loaded onto smartcard incrementally and linked on-card for execution so that thefunctionality of the smart card may be updated with additionalcapabilities in addition to factory-programmed functionalities. In thediagram, a Java™ language framework 285 and a Java Card™ framework 280exist at a Java Card™ API level. Above the Java Card™ API level is acustom API level with one or more custom frameworks 290. The customframework 290 may be supplied by one or more value added providersthrough various software development kits (SDKs) to extend an existingframework or other API. At the highest level is an application levelwhere various applets 295, 300 and 305 reside.

Each of the boxes shown in FIG. 6 represents a Java™ package. A packageis called a library package if it exports items and is thereforereferenced by other packages. A package is called an applet package ifit contains a program entry point. Some packages are both library andapplet packages.

As shown in FIG. 6, a package may depend on other packages at the sameAPI level or from those packages in lower API levels. The Java Card™framework 280 may have dependencies from the Java™ language framework285. Moreover, the custom framework 290 at the custom API level and theapplets 300 and 305 may have references that depend from the Java Card™framework 280. In turn, the applet 295 may have references that dependon the custom framework 290. The applet 295 and the custom framework 290may also depend on the Java™ language framework 285. Applets may alsodepend on one another as shown by the line from Applet 305 to Applet300. In this case, Applet 300 is both an applet and library package.

Although the example of FIG. 6 shows linear dependencies, non-lineardependencies such as circular dependencies may be supported using asuitable converter and installation tool.

Post-Issuance Install

The Java Card™ CAP file format provides for the post issuanceinstallation of applications. In other words, the CAP file allows thecontent of a resource-constrained device to be updated after the devicehas been issued to an end user. The capability to install applicationsafter the card has been issued provides card issuers with the ability torespond dynamically to their customer's changing needs. For example, ifa customer decides to enroll in the frequent flyer program associatedwith the card, the card issuer can add this functionality, withouthaving to issue a new card.

The Java Card™ CAP file format thus provides more flexibility forapplication issuers. Application issuers may implement transactionalservices as applets, and then host these applets, either in their owncards or in the cards of other issuers with whom they do business. Forexample, an issuer may provide a core service to clients in the form ofJava™ applets for the issuer's cards. The clients will then combinethese applets with other applets designed to provide a variety of valueadded services. These applet combinations can be updated through thedynamic applet loading process to meet the changing needs of individualcustomers.

Turning now to FIG. 7, a block diagram that illustrates preparation of aresource-constrained device without post-issuance installation ispresented. A manufacturer typically prepares the resource-constraineddevice by loading it with some initial content (310). This initialcontent typically includes the native OS, Java Card™ and some or all ofthe Java Card™ API packages (320). Some initial applets and/or librariesmay be provided by an applet or library provider (315). The initialcontent is burned into ROM. This process of writing the permanentcomponents into the non-mutable memory of a chip for carrying outincoming commands is called masking. The manufacturer may also loadgeneral data onto the card's non-volatile memory. This data is identicalacross a large number of cards and is not specific to an individual. Anexample of this general data is the name of a card manufacturer.

Typically, the manufacturer also personalizes the content of a card byassigning the card to a person. This may occur through physicalpersonalization or through electronic personalization. Physicalpersonalization refers to permanently marking by, for example, embossingor laser engraving the person's name and card number on the physicalsurface of a card. Electronic personalization refers to loading personaldata into a card's non-volatile memory. Examples of personal datainclude a person's name, personal ID or PIN number, and personal key.

Next, an issuer 320 obtains an initialized device from the manufacturer.The issuer may obtain additional applets or libraries from a providerand load the additional content onto the device. This furthercustomization of the cards is performed by installing the applets orlibraries in the form of CAP files. The issuer may also load generaldata, such as the issuer name, into the card's non-volatile memory.

After preparing the cards (320), the issuer disables subsequentinstallation of libraries or applets on the device and distributes thedevice to an end user 325. At this point, the card is ready for usehaving its complete content. Since installation has been disabled, nofurther content will be added after the card has been issued. The cardmay be obtained from an issuer, or it can be bought from a retailer.Cards sold by a retailer can be general-purpose, in which casepersonalization is often omitted.

Turning now to FIG. 8, a block diagram that illustrates preparation of aresource-constrained device with post-issuance installation ispresented. The diagram illustrates the case where a “trusted” installer330 installs additional content on the device after the device has beenissued to the end user 335. The post-issuance installer 330 is “trusted”because of a preexisting agreement between the post-issuance installer330 and the issuer 340. In this case, the issuer 340 distributes thedevice to the end user 335 without disabling subsequent installations.The end user may update the content of the resource-constrained deviceby presenting it to a “trusted” post-issuance installer 330. The“trusted” post-issuance installer 330 installs additional content on theresource-constrained device and returns it to the end user 335. Theinstallation is performed by transmitting a CAP file to the device.

In the scenario illustrated in FIGS. 7 and 8, the roles of themanufacturer, issuer, services provider and applet provider aredescribed. These roles can be filled by one or more entities.

Typically, each of the roles described in FIGS. 7 and 8 entail testingthe applets and packages before they are installed on the device.Testing checks the functional behavior of these modules, confirming thatgiven a particular input a required output is produced. Testing examinesa different domain than verification, described above.

A Java Card™ system may be constructed incrementally and at each stage,it is desirable to ensure program integrity. For example, themanufacturer may populate a resource-constrained device with one or morelibraries. Before shipping, it would be desirable for the manufacturerto guarantee the content integrity. At this stage, there are onlylibraries on the device, and no applets. Without an applet, there is noapplet entry point and therefore no execution path for a verifier tofollow. If an issuer then adds an applet, it would be desirable continueto ensure the content integrity. Accordingly, a need exists in the priorart for a system and method for remote program verification thataccounts for iterative installation. There is a further need for asystem and method for resource-constrained device program verificationthat protects against untrusted post-issuance installers.

Binary Compatibility

In Java Card™ technology, a change to a type in a Java™ package resultsin a new CAP file. A new CAP file is binary compatible with apreexisting CAP file if another CAP file converted using the export fileof the preexisting CAP file can link with the new CAP file withouterrors.

The Java™ Language Specification includes several examples of binarycompatible changes for the Java™ language. These examples include addinga class and adding a field to a class. Examples of binary incompatiblechanges include deleting a class and changing the parameters to amethod.

The Java Card™ Virtual Machine specification defines binary compatiblechanges to be a strict subset of those defined for the Java™ programminglanguage. An example of a binary compatible change in the Java™programming language that is not binary compatible in the Java Card™platform is adding a public virtual method to a class that can beextended by a referencing binary file.

Turning now to FIG. 9, a block diagram that illustrates binarycompatibility is presented. FIG. 9 shows an example of binary compatibleCAP files, P1 (360) and P1′ (365). The preconditions for the exampleare: The package P1 is converted to create the P1 CAP file (360) and P1export file (370), and package P1 is modified and converted to createthe P1′ CAP file (365). Package P2 imports package P1, and thereforewhen the P2 CAP file (375) is created, the export file of P1 (370) isused. In the example, P2 is converted using the original P1 export file(370). Because P1′ is binary compatible with P1, P2 may be linked witheither the P1 CAP file (360) or the P1′ CAP file (365).

The Java Card™ Virtual Machine further specifies that major and minorversion numbers be assigned to each revision of a binary file. Theseversion numbers are record in both CAP and export files. When the majorversion numbers of two revisions are not equal, the two revisions arenot binary compatible. When the major version numbers of the tworevisions are equal, the revision with the larger minor version numberis binary (backward) compatible with the revision with the smaller minorversion number.

The major and minor versions of a package are assigned by the packageprovider. A major version is changed when a new implementation of apackage is not binary compatible with the previous implementation. Thevalue of the new major version is greater than the version of theprevious implementation. When a major version is changed, the associatedminor version is assigned the value of 0.

When a new implementation of a package is binary compatible with theprevious implementation, it is assigned a major version equal to themajor version of the previous implementation. The minor version assignedto the new implementation is greater than the minor version of theprevious implementation.

Both an export file and a CAP file contain the major and minor versionnumbers of the package described. When a CAP file is installed on a JavaCard™ enabled device, a resident image of the package is created, andthe major and minor version numbers are recorded as a part of thatimage. When an export file is used during preparation of a CAP file, theversion numbers indicated in the export file are recorded in the CAPfile.

During installation, references from the package of the CAP file beinginstalled to an imported package can be resolved only when the versionnumbers indicated in the export file used during preparation of the CAPfile are compatible with the version numbers of the resident image. Theyare compatible when the major version numbers are equal and the minorversion of the export file is less than or equal to the minor version ofthe resident image.

Any modification that causes binary incompatibility in Java Card™systems may cause an error at run time. Accordingly, an additional needexists in the prior art for a system and method for program verificationthat ensures binary compatibility.

SUMMARY OF THE INVENTION

A method for remote incremental program verification includes receivingcontent verified by at least one content provider, installing thecontent on a resource-constrained device and issuing theresource-constrained device to an end user. The content includes atleast one program unit and each program unit includes an ApplicationProgramming Interface (API) definition file and an implementation. EachAPI definition file defines items in its associated program unit thatare made accessible to one or more other program units and eachimplementation includes executable code corresponding to the APIdefinition file. The executable code includes type specific instructionsand data. According to one aspect, subsequent installation of content onthe resource-constrained device is disabled. A resource-constraineddevice includes a memory for providing content verified by at least onecontent provider and a virtual machine that is capable of executinginstructions included within the content. The content includes at leastone program unit and each program unit includes an ApplicationProgramming Interface (API) definition file and an implementation. EachAPI definition file defines items in its associated program unit thatare made accessible to one or more other program units, eachimplementation includes executable code corresponding to the APIdefinition file, and executable code includes type specific instructionsand data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level flow diagram that illustrates programverification.

FIG. 2 is a high level flow diagram that illustrates verification of anapplication to be executed on a resource-rich device.

FIG. 3 is a block diagram that illustrates the need for programverification.

FIG. 4 is a block diagram that illustrates development of an applet fora resource-constrained device.

FIG. 5 is a block diagram that illustrates a Converted Applet (CAP) fileformat.

FIG. 6 is a block diagram that illustrates hierarchical dependenciesbetween application packages.

FIG. 7 is a block diagram that illustrates preparation of aresource-constrained device without post-issuance install.

FIG. 8 is a block diagram that illustrates preparation of aresource-constrained device with post-issuance install.

FIG. 9 is a block diagram that illustrates binary compatibility.

FIG. 10A is a flow diagram that illustrates verification that follows anexecution path.

FIG. 10B is a code sample that illustrates verification that follows anexecution path.

FIG. 10C is a flow diagram that illustrates verification that follows anexecution path to an API in accordance with one embodiment of thepresent invention.

FIG. 10D is a code sample that illustrates verification that follows anexecution path to an API in accordance with one embodiment of thepresent invention.

FIG. 11A is a block diagram that illustrates one embodiment of thepresent invention.

FIG. 11B is a block diagram that illustrates verification on a resourcerich device in accordance with one embodiment of the present invention.

FIG. 11C is a block diagram that illustrates verification on a terminaldevice in accordance with one embodiment of the present invention.

FIG. 12 is a high level flow diagram that illustrates a verificationmethod in accordance with one embodiment of the present invention.

FIG. 13A is a block diagram that illustrates verification relationshipsusing Application Programming Interface (API) definitions in accordancewith one embodiment of the present invention.

FIG. 13B is a block diagram that illustrates implementation-independentverification using an API definition file with multiple implementationsin accordance with one embodiment of the present invention.

FIG. 14 is a flow diagram that illustrates incrementally constructing averified system in accordance with one embodiment of the presentinvention.

FIG. 15A is a block diagram that illustrates verification andinstallation of an initial library in accordance with one embodiment ofthe present invention.

FIG. 15B is a block diagram that illustrates verification andinstallation of an applet that references a library in accordance withone embodiment of the present invention.

FIG. 16 is a flow diagram that illustrates verifying a library or appletin accordance with one embodiment of the present invention.

FIG. 17 is a flow diagram that illustrates verifying external referencesusing an API definition file in accordance with one embodiment of thepresent invention.

FIG. 18 is a flow diagram that illustrates verifying a package with itscorresponding API definition file in accordance with one embodiment ofthe present invention.

FIG. 19 is a flow diagram that illustrates loading a library or appletonto a resource-constrained device in accordance with one embodiment ofthe present invention.

FIG. 20A is a block diagram that illustrates verification using APIdefinition files of backward compatible revisions in accordance with oneembodiment of the present invention.

FIG. 20B is a block diagram that illustrates verification using APIdefinition files of backward compatible revisions in accordance with oneembodiment of the present invention.

FIG. 20C is a flow diagram that illustrates verifying versions using APIdefinition files in accordance with one embodiment of the presentinvention.

FIG. 20D is a flow diagram that illustrates verifying that the contentof a new API definition file is backward compatible with the content ofan old API definition file in accordance with one embodiment of thepresent invention.

FIG. 21A is a block diagram that illustrates verification withoutpost-issuance installation in accordance with one embodiment of thepresent invention.

FIG. 21B is a block diagram that illustrates verification with trustedpost-issuance installation in accordance with one embodiment of thepresent invention.

FIG. 21C is a block diagram that illustrates verification with untrustedpost-issuance installation in accordance with one embodiment of thepresent invention.

FIG. 21D is a block diagram that illustrates verification includingbinary compatibility with untrusted post-issuance installation inaccordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Those of ordinary skill in the art will realize that the followingdescription of the present invention is illustrative only. Otherembodiments of the invention will readily suggest themselves to suchskilled persons having the benefit of this disclosure.

This invention relates to computer systems. More particularly, thepresent invention relates to a system and method for remote distributedprogram verification using API definition files. The invention furtherrelates to machine-readable media on which are stored (1) the layoutparameters of the present invention and/or (2) program instructions forusing the present invention in performing operations on a computer. Suchmedia includes by way of example magnetic tape, magnetic disks,optically readable media such as CD ROMs and semiconductor memory suchas PCMCIA cards. The medium may also take the form of a portable itemsuch as a small disk, diskette or cassette. The medium may also take theform of a larger or immobile item such as a hard disk drive or acomputer RAM.

According to embodiments of the present invention, a verifier uses APIdefinition files of program modules to perform inter-module consistencychecks. Each program has an associated verification status value that isTrue if the program's integrity is verified by the verifier, and it isotherwise set to False. Use of the verifier in accordance with thepresent invention enables verification of a program's integrity andallows the use of an interpreter that does not execute the usual stackmonitoring instructions during program execution, thereby greatlyaccelerating the program interpretation process.

According to embodiments of the present invention, verification does notcontinue beyond an API definition file. This differs from typicalverification methods that continue the verification process into animplementation of the API definition file. An API definition filedefines the context of a binary file in relationship to other referencedbinary files. Once it is shown that binary files are implemented inaccordance with their API definition files, binary files that referenceitems in other binary files need only look to the API definition filesof whatever binary files implement those items to determine whether twobinary files are compatible. Verifying that a binary file is implementedin accordance with its API thus obviates the need for other binary filesthat reference the verified binary file to continue the verificationprocess into the verified binary file because it has already beenverified. Using API definition files in accordance with the presentinvention therefore provides a mechanism for making conclusionsregarding whether a referencing program passes verification, without thedisadvantages of typical known verification methods.

FIGS. 10A to 10D illustrate the two approaches for verificationdiscussed above. FIGS. 10A and 10B illustrate typical verificationmethods that continue the verification process into an implementationthat includes externally referenced items. FIGS. 10C and 10D illustrateverification that uses API definition files to verify a program unitthat includes external references in accordance with the presentinvention.

The examples in FIGS. 10A and 10B illustrate analysis which is typicallyperformed during verification using a virtual stack. The virtual stackis validated and updated during verification based on the operationsdefined for instructions in a method. (For examples of virtual stackusage during verification, See U.S. Pat. No. 5,668,999 to Gosling, U.S.Pat. No. 5,748,964 to Gosling and U.S. Pat. No. 5,740,441 to Yellin etal.)

Turning now to FIG. 10A, a flow diagram that illustrates verificationthat follows an execution path is presented. At 400, a bytecode programis loaded into a verifier and the verifier is initialized. At 405, theinstruction pointer is set to the first instruction in the program. At410, a determination is made regarding whether the instruction is amethod invocation instruction. If the instruction is not a methodinvocation instruction, the instruction is verified at 435. If theinstruction is a method invocation instruction, at 415, a determinationis made regarding whether the current virtual stack matches the list ofexpected parameter and result types, also referred to as the methodsignature, found in the binary file that contains the referenced method.If there is no match, a verification error is indicated at 430. If thereis a match, at 420, the invoked method is verified. At 425 adetermination is made regarding whether the invoked method wassuccessfully verified. If the invoked method was not successfullyverified, a verification error is indicated at 430. At 440, adetermination is made regarding whether the current instruction is thelast instruction. If the current instruction is not the lastinstruction, verification continues with the next instruction at 445.Verification terminates at 450 when the last instruction has beenexamined.

With respect to reference numerals 415-425 of FIG. 10A, when a methodinvocation instruction is encountered during verification that iscoupled with execution, a typical verifier performs the followingoperations pertaining to the content of the referencing binary file.

1. The calling context is verified to determine whether it hasappropriate permission to reference the method found in the referencedbinary file. For example, a protected method can only be invoked by amethod in a subclass of or a member of the class in which the method isdeclared.

2. The arguments found on the virtual stack at the point of invocationin the referencing binary file are verified to determine whether theyare appropriate given the declaration of the invoked method found in thereferenced binary file.

3. The virtual stack is updated by removing the arguments to the invokedmethod and adding the return type, if any, of the invoked method. Thereturn type is defined in the referenced binary file.

4. Verification of the referencing binary file continues at theinstruction after the method invocation using the updated virtual stack.

Typically, either before step 1 or between steps 2 and 3, the referencedbinary file is verified. Regardless of the exact timing, whenverification is coupled with execution, a referenced binary file isverified before it is executed.

The example shown in FIG. 10A does illustrate verification of referencesto non-methods such as classes, interfaces and fields. Typically,verification of such non-method references also entails examining thereferenced items. Furthermore, when examining such referenced items, thereferenced binary file that contains the referenced item is alsotypically verified.

Turning now to FIG. 10B, a code sample that illustrates verificationthat follows an execution path is presented. FIG. 10B includes codesamples for a library package L0 500 and applet A1 505. Applet A1 505includes references to items in package L0 500. FIG. 10A alsoillustrates a virtual stack before (510) and after (515) verification ofmethod invocation instructions in L0 500 and A1 505. Method A10 520references method A11 525 at reference numeral 530. Method A11 525references method L01 535 at reference numeral 540. Method L01 535references method L02 545 at reference numeral 550.

Verification of applet A1 505 begins with method A10 520. At 530, methodA10 520 invokes method A11 525 with the short integer parameter S 555and assigns the result to byte array ba 560. In preparation for themethod A11 525 invocation, the method A11 525 parameter types are put onthe stack. In Java™ technology, values of type byte, short and integerare represented as integer types on the stack. Thus, before invokingmethod A11 525, the virtual stack 560 contains type int, the type for S555. This matches the declaration of method A11 525 found in the A1binary file 505.

At 540, method All 525 invokes method L01 535 and assigns the result tobyte array type ba 565. Before invoking method L01 535, the virtualstack 570 contains a reference to class A1. The expected type is typeObject 575. A1 570 is assignment-compatible with Object 575 because A1570 extends Object (580). This matches the declaration of method L01 535found in the L0 binary file 500.

At 575, method L01 535 invokes method L02 545 and assigns the result tofloat value f 585. Before invoking method L02 550, the virtual stack 590contains a reference to class Object. The virtual stack 590 alsocontains an integer type corresponding to integer I 595. This matchesthe declaration of method L02 545 found in the L0 binary file 500.

Next, the virtual stack is updated by removing the arguments to theinvoked method and adding the return type, if any, of the invokedmethod. The return type is defined in the referenced binary file. In theabove example, method L02 545 returns float type f 600, which matchesthe method L02 return type of float f 605. Method L01 535 returns aninteger type. At 565, the returned integer type is explicitly cast totype byte, which matches the type of ba[0] 610. Method A11 525 returns abyte array, which corresponds to the type of byte array ba 560.

Thus, method A10 520 has been verified by examining the content ofmethod A10 520 and the binaries of all compilation units referenced bymethod A10 520.

Verification using an API definition file according to embodiments ofthe present invention follows the same four steps shown above withreference to FIG. 10A, except that information about the invoked methodis obtained from an API definition file instead of a binary file. Theconclusions drawn regarding verification of the referencing binary fileare the same in both cases. In addition, at some point duringverification, the API definition file is verified for internalconsistency. This step is parallel to verifying a referenced binaryfile. Furthermore, during verification using an API definition fileaccording to embodiments of the present invention, the assumption ismade that an implementation of the API definition file has been verifiedin a previous operation and that the implementation is complainant withthe API definition file. This is described in more detail with referenceto FIGS. 10C and 10D.

Turning now to FIG. 10C, a flow diagram that illustrates verificationthat follows an execution path to an API definition file in accordancewith one embodiment of the present invention is presented. At 700, averifier receives a bytecode program and the verifier is initialized. At705, the instruction pointer is set to the first instruction in theprogram. At 710, a determination is made regarding whether the currentinstruction is a method invocation to an external method. If the currentinstruction is not a method invocation to an external method, theinstruction is verified at 730. If the instruction is a methodinvocation instruction, at 715, a determination is made regardingwhether the virtual stack matches the method signature found in an APIdefinition file that corresponds to the binary file of the invokedmethod. If the virtual stack does not match the method signature, averification error is indicated at 725. If the virtual stack matches themethod signature, the virtual stack is updated at 720. At 735, adetermination is made regarding whether the current instruction is thelast instruction. If there is another instruction, the next instructionis pointed to at 740 and verification continues at 710. Verificationends at 745 when the last instruction has been examined. A detailedexample that illustrates this process is described with reference toFIG. 10D.

Turning now to FIG. 10D, a code sample that illustrates verificationthat follows an execution path to an API in accordance with oneembodiment of the present invention is presented. FIG. 10D includes codesamples for a library package L0 800 and applet A1 805. Applet A1 805includes references to items in package L0 800. FIG. 10D alsoillustrates a virtual stack before (810) and after (815) execution ofsource code statements in L0 800 and A1 805. Method A10 820 referencesmethod A11 825 at reference numeral 830. Method A11 825 referencesmethod L01 835 at reference numeral 840.

Verification of applet A1 805 begins with method A10 820. At 830, methodA10 820 invokes method A11 825 with the short integer parameter S 845and assigns the result to byte array ba 850. In preparation for themethod A11 invocation (830), the method A11 825 parameter types are puton the stack 850. As mentioned above, in Java™ technology, values oftype byte, short and integer are represented as integer types on thestack. Thus, before invoking method A11 825, the virtual stack 850contains type int, the type for S 845. This matches the declaration ofmethod A11 825 found in the A1 binary file 805.

At 840, method A11 825 invokes method L01 835 and assigns the result tobyte array type ba 855. Before invoking method L01 835, the virtualstack 860 contains a reference to class A1. The expected type is typeObject 865. A1 860 is assignment-compaitble with Object 865 because A1860 extends Object (870). This matches the declaration of method L01 835found in the L0 API definition file 800.

Next, the virtual stack is updated by removing the arguments to theinvoked method and adding the return type, if any, of the invokedmethod. The return type is defined in the referenced API definitionfile. In the above example, method L01 875 returns an integer type. At855, the returned integer type is explicitly cast to type byte, whichmatches the type of ba[0] 880. Method A11 825 returns a byte array,which corresponds to the type of byte array ba 850.

Thus, method A10 820 has been verified without reference to the binaryfiles containing compilation units referenced by method A10 820.Instead, method A10 820 has been verified by examining the content ofmethod A10 820 and the API definition files of all compilation unitsreferenced by method A10 820.

The description regarding verification in FIGS. 10C and 10D illustratedverification with respect to a method. This example is intended forillustrative purposes only. Those of ordinary skill in the art willrecognize that verification of other references may be performed in asimilar manner using an API definition file. These references include byway of example, references to fields, classes and interfaces.

Referring now to FIG. 11A, there is shown a distributed computer systemhaving multiple client computers 980, 1090 and multiple server computers985. In one embodiment, each client computer 980, 1090 is connected tothe servers 985 via the Internet 1055, although other types ofcommunication connections could be used. While most client computers aredesktop computers, such as Sun workstations, IBM compatible computersand Macintosh computers, virtually any type of computer can be a clientcomputer. In one embodiment, each client computer includes a CPU 990, auser interface 995, a memory 1000, Internet access processor 1035 and acommunications interface 1005. Client memory 1000 stores:

-   -   an operating system 1010;    -   a program converter 1015, which converts binary file and related        API definition files into optimized binary files and API        definition files;    -   a program verifier 1020 for verifying whether or not a specified        program satisfies certain predefined integrity criteria;    -   at least one optimized binary file repository 1025, for locally        storing optimized binary files in use and/or available for use        by users of the computer 1000;    -   at least one API definition file repository 1030 for storing        export files.

The converter 1015 converts a binary file into an optimized binary fileand an API definition file of the optimized binary file. If the binaryfile includes external reference, the converter 1015 uses the APIdefinition file stored in 1030 of the module including the externalreference to verify the external reference.

According to one embodiment of the present invention, theresource-constrained device is a Java Card™ enabled device. In thisembodiment, the API definition file is Java Card™ export file, thebinary file is a class file and the optimized binary file is a CAP file.Also, the methods in a class to be loaded are bytecode programs, whichwhen interpreted will result in a series of executable instructions.According to this embodiment, the bytecode program verifier 1020verifies the integrity of the bytecode programs in a CAP file withreference to the CAP file, the export file corresponding to the CAPfile, and the export file containing externally referenced items. If allthe methods are successfully verified, the CAP file is sent to theresource-constrained device 1040 via a terminal device 1045.

As shown in FIG. 11A, a terminal 1045 is equipped with a card acceptancedevice (CAD) 1050 for receiving a card. The terminal 1045 may beconnected to a network 1055 that communicates with a plurality of othercomputing devices, such as a server 985. It is possible to load data andsoftware onto a smart card over the network 1055 using card equippeddevices. Downloads of this nature include applets or libraries to beloaded onto a smart card as well as digital cash and other informationused in accordance with a variety of electronic commerce and otherapplications. The verified instructions and data used to controlprocessing elements of the card acceptance device and of the smart cardmay be stored in volatile or non-volatile memory or may be receiveddirectly over a communications link e.g., as a carrier wave containingthe instructions and/or data. Further, for example, the network 1055 canbe a LAN or WAN such as the Internet or other network.

The third computer node 1040, assumed here to be configured as smartcard or other resource-constrained device, includes a microprocessor1060, a memory 1065, and an I/O port 1070 that connects the secondcomputer node to the terminal device 1045. Resource-constrained devicememory 1065 stores programs for execution by the processor 1060.

Resource-constrained device memory 1065 stores:

-   -   an operating system 1080;        -   a loader 1085 for loading a verified optimized binary file            via I/O port 1070;        -   an interpreter 1050 for executing a module within an            optimized binary file;        -   at least one program 1075 for execution by microprocessor            1060.

The first, second and third computer nodes 980, 1045 and 1040 mayutilize different computer platforms and operating systems 1010, 1080such that object code program executed on either one of the two computernodes cannot be executed on the other. For instance, the server node 985might be a Sun Microsystems computer using a Unix operating system whilethe user workstation node 980 may be an IBM compatible computer systemusing a Pentium III microprocessor and a Windows 98 operating system.Furthermore, other user workstations coupled to the same network andutilizing the same server 985 might use a variety of operating systems.

According to embodiments of the present invention, verification isperformed before the module is loaded on a resource-constrained device,herein referred as remote verification. According to one embodiment ofthe present invention, verification is performed on a resource-richdevice such as a desktop PC, as illustrated in FIG. 11A. According toanother embodiment of the present invention, remote verification isperformed on a terminal device, as illustrated in FIG. 11B.

Turning now to FIG. 11B, a block diagram that illustrates verificationon a resource-rich device before installation in accordance with oneembodiment of the present invention is presented. A verifier 1110resident on the resource-rich device 1100 verifies the optimized binaryfile 1105. The optimized binary file 1105 is transferred to a terminaldevice 1115 having an installer 1120. The installer 1120 communicateswith a loader 1130 on a resource-constrained device 1125 to load theverified optimized binary file.

According to one embodiment of the present invention the loader confirmsthat the context in which the binary file will be linked and executed iscompatible with the context of the API definition files used duringverification. Additionally, the context of a verified and loaded binaryfile must not be allowed to change in to an incompatible state. In aJava Card™ compliant system, this requirement is fulfilled by ensuringthat a referenced binary file is never deleted or updated.

Turning now to FIG. 11C, a block diagram that illustrates verificationon a terminal device before installation in accordance with oneembodiment of the present invention is presented. The optimized binaryfile 1155 is transferred to a terminal device 1165 having an off-deviceinstaller 1170. A verifier 1160 resident on the terminal device 1165verifies the optimized binary file 1155. The installer 1170 communicateswith a loader 1180 on a resource-constrained device 1175 to load theverified optimized binary file.

Turning now to FIG. 12, a flow diagram that illustrates verification inaccordance with one embodiment of the present invention is presented. At1200, a library or applet is received. At 1205, the library or applet isverified using the applet binary file, the API definition file of thelibrary or applet if it exports items, and the API definition file ofany binary files containing items referenced by the applet binary file.At 1210, the library or applet is stored in a secure state to protectagainst unauthorized modification. At 1215, the library or applet isloaded for subsequent linking and execution on a resource-constraineddevice.

Turning now to FIG. 13A, a block diagram that illustrates verificationrelationships using Application Programming Interface (API) definitionsin accordance with one embodiment of the present invention is presented.FIG. 13A illustrates the process of verifying applet A1. In thisexample, A1 is an applet that references the library L1. Library L1includes a reference to Library L0. Verification proceeds as follows:First, the L0 API definition file 1230 is verified with the L0 binaryfile 1235. Next, the L1 binary file 1240 is verified with the L0 APIdefinition file 1230. Next, the L1 API definition file 1245 is verifiedwith the L1 binary file 1240. Verification of the L1 binary file 1240with the L0 API definition file 1230 thus indicates the L1 binary file1240 is verified with the L0 binary file 1235. Next, the A1 binary file1250 is verified with the L1 API definition file 1245. Verification ofthe A1 binary file 1250 with the L1 API definition file 1245 thusindicates the A1 binary file 1250 is verified with the L1 binary file1240. Thus, a fully verified collection of binary files (A1 1250, L11245 and L0 1230) has been constructed.

As mentioned previously, an API specifies how one program module mayinteract with another. Different vendors may implement an API indifferent ways, as long as they adhere to the API definition file. Forexample, one vendor may choose to implement a method that sorts a set ofvalues using an algorithm optimized for speed, while another vendor maychoose to implement an algorithm optimized for low memory usage. In bothcases, the implementations would be compliant with an API definitionfile containing a method that performs a sort, and vary inimplementation details.

According to embodiments of the present invention, verification does notdepend upon a particular implementation. More specifically, if areferencing binary file references an API and there is more than oneimplementation for that API, the referencing binary file is said to beverified with each implementation if the referencing binary fileverifies with the referenced API and if each implementation of the APIverifies with the referenced API definition file. This example isillustrated in FIG. 13B.

Turning now to FIG. 13B, a block diagram that illustratesimplementation-independent verification using an API definition filewith multiple implementations in accordance with one embodiment of thepresent invention is presented. In the example, L1 is a library thatreferences library L0. Library L0 has two implementations from twodifferent vendors, vendor 1 implemented 1270 and vendor 2 implemented1275. Both the L0 binary file from vendor 1 (1270) and the L0 binaryfile from vendor 2 (1275) are verified with the L0 API definition file1265. Next, the L1 binary file 1260 is verified with the L0 APIdefinition file 1265. Since both L0 binary files 1270 and 1275 areverified against the L0 API definition file 1265 and since the L1 binaryfile 1260 is verified against the L0 API definition file 1265, the L1binary file 1260 is verified against both particular implementations ofL0, that is binary files 1270 and 1275. Thus, two fully verifiedcollections of binary files have been constructed: 1) L1 binary file1260 and L0 binary file provided by vendor 1 (1270); and 2) L1 binaryfile and L0 binary file provided by vendor 2 (1275).

As shown in FIG. 13B, verification applies to all permutations oflinking. Thus, when binary file L1 (1260) is installed on oneresource-constrained device, it may be linked with the L0 binary filefrom vendor 1 (1270). It may also be installed on anotherresource-constrained device and linked with the L0 binary file fromvendor 2 (1275).

The number of implementations illustrated in FIG. 13B is not intended tobe limiting in any way. Those of ordinary skill in the art willrecognize that the invention is applicable when more that twoimplementations are provided.

According to one embodiment of the present invention, programverification is performed iteratively, one program module at a time.This is also called distributed verification. Referring to FIG. 14, aflow diagram that illustrates incrementally constructing a verifiedsystem in accordance with one embodiment of the present invention ispresented. An initial library is verified (1280), stored in a securestate (1285) and loaded (1290). At 1295, the API definition file of theinitial verified library is provided for use by client libraries orapplets that reference library. Each client library or applet isverified (1300), stored in a secure state (1305) and loaded (1310). At1315, a check is made to determine whether the client exports any items.If the client exports any items, the API definition file of the clientlibrary is provided for use by other libraries or applets that referencethe client library (1295).

According to another embodiment of the present invention, the loading ofverified libraries and applets is delayed until all the libraries andapplets required for an update have been verified. In both this case andthe embodiment described immediately above, the process of performingverification using API definition files is the same.

Turning now to FIG. 15A, a block diagram that illustrates verificationand installation of an initial library in accordance with one embodimentof the present invention is presented. In this example, theresource-constrained device 1320 contains a loader 1325, an interpreterand I/O services 1330. No libraries or applets have been installed atthis point. This initial content provides the foundation for installingand executing libraries and applets. First, a verifier 1335 on aresource-rich device 1340 verifies the L0 binary file 1345, the libraryto be added. The resource-rich device may be by way of example, adesktop PC or a terminal device. Verification of the L0 binary file 1345includes verifying the L0 binary file 1345 and verifying the L0 APIdefinition file 1350 with the L0 binary file 1345. Next, the verified L0binary file 1345 is installed on a resource-constrained device 1320.After installation, the content of the resource-constrained device 1320is said to be verified.

Turning now to FIG. 15B, a block diagram that illustrates verificationand installation of an applet that references a library in accordancewith one embodiment of the present invention is presented. In thisexample, resource-constrained device 1360 has been initialized withlibrary L0 (see FIG. 15A) and applet A1 is to be added to theresource-constrained device 1360. Applet A1 binary file 1365 referenceslibrary L0. Since the L0 binary file 1370 has already been verified withits corresponding L0 API definition file 1375 and installed, theverified API definition file for L0 1375 is resident on theresource-rich device 1380. The A1 binary file 1365 is verified using theAPI definition file of the referenced library, L0 1375. Afterverification, the A1 binary file 1365 is installed on theresource-constrained device. After installation, the content of theresource-constrained device (A1 binary file 1365 and L0 binary file1370) is said to be verified.

Those of ordinary skill in the art will recognize that the scenariosillustrated in FIGS. 15A and 15B can be combined to verify and install amodule that both references a library and exports an API. The module'sexported API definition file will be available to be referenced bysucceeding binary files.

Turning now to FIG. 16, a flow diagram that illustrates verifying alibrary or applet in accordance with one embodiment of the presentinvention is presented. At 1400, a library or applet package isreceived. At 1405, intra-module checks are performed to determinewhether the package is internally consistent. At 1410, inter-modulechecks are performed to determine whether the external references of thepackage are consistent within the context of the API definition file ofeach external reference. At 1415, a check is made to determine whetherthe package exports any items. If the package exports items, the currentpackage is verified against its API definition file (1420).

The order of the intra-module checks and the inter-module checks shownin FIG. 16 is not intended to indicate a required order of operations.During program verification that follows an execution path, those ofordinary skill in the art will recognize that when intra-module checksor inter-module checks are performed can depend on the context of theelement being verified. When performing intra-module checks, if anelement is encountered that references an external item, an inter-modulecheck can be performed immediately. Alternatively, all inter-modulechecks can be postponed and performed in one step as shown in FIG. 16.

The intra-module checks may include by way of example, verifying binaryfile format and verifying that:

-   -   a class is not a subclass of a “final” class,    -   no method in the class overrides a “final” method in a        superclass,    -   each class, other than “Object” has a superclass,    -   class reference, field reference and method reference in the        constant pool has a legal name, class and type signature.

See, for example, U.S. Pat. No. 5,668,999 to Gosling, U.S. Pat. No.5,748,964 to Gosling and U.S. Pat. No. 5,740,441 to Yellin et al.

Turning now to FIG. 17, a flow diagram that illustrates verifyingexternal references using an API definition file in accordance with oneembodiment of the present invention is presented. FIG. 17 provides moredetail for reference numeral 1410 in FIG. 16. At 1430, a program unitsuch as a library or applet package is received. If the API definitionfile of the referenced package is not found, a verification error isindicated. At 1435, the API definition file of the referenced package isloaded. At 1440, the package attributes are compared. The packageattributes may include by way of example, the package name and version.If the package attributes are not compatible, a verification error isindicated.

At 1445, for each referenced class and interface, the usage of the classor interface in the binary file is compared to the corresponding usagein the API definition file. If the class or interface is not found inthe API definition file, a verification error is indicated. If usage ofthe class or interface is not compatible, a verification error isindicated. An example of an incompatibility is an attempt to create aninstance of an abstract class or interface.

At 1450, for each referenced field, the field is located in the APIdefinition file, and the usage of the field in the binary file iscompared to the corresponding definition in the API. If the field is notfound in the API definition file, a verification error is indicated. Ifthe usage of the field is not compatible, a verification error isindicated. An example of an incompatibility is an attempt to store afloating-point value into a field that is declared as an integer(int)-type in the API definition file.

At 1455, for each referenced method, the method is located in the APIdefinition file, and the usage of the method in the binary file iscompared to the definition in the API. If the method is not found in theAPI definition file, a verification error is indicated. If the usage ofthe method is not compatible, a verification error is indicated. Anexample of an incompatibility is an attempt to invoke a method withoutpassing in any parameters when the method is declared in the APIdefinition file to require one parameter of the specified type (int).

Those of ordinary skill in the art will recognize that locating andverifying usage against definitions in an API definition file can beperformed sequentially in one step as shown in FIG. 16. Alternatively,locating and verifying usage against definition can be performed as theusage is encountered.

Turning now to FIG. 18, a flow diagram that illustrates verifying apackage with its corresponding API definition file in accordance withone embodiment of the present invention is presented. FIG. 18 providesmore detail for reference numeral 1420 in FIG. 16. FIG. 18 is notintended to indicate the order in which the various checks areperformed. A library or applet package (herein referred to as a binaryfile) is received (1460) and the API definition file of the package isreceived (1465). If the API definition file of the package is not found,and the binary file exports elements, a verification error is indicated.

At 1470, the package attributes are compared. The attributes may includeby way of example, the package name, version and number of classes andinterfaces. Continuing this example, this step detects whether an extraclass or interface is defined in the API definition file that is notpresent in the binary file. If the attributes are incompatible, averification error is indicated.

Several checks are performed to verify each exported class and interfacein the binary file. At 1475, the class or interface is located in theAPI definition file and the attributes of the class or interface asdefined in the API definition file are compared to the definition of theclass or interface in the binary file. If the class or interface is notfound in the API definition file, a verification error is indicated. Theattributes may include by way of example, the class name, flags, numberof fields and number of methods. Continuing this example, this stepdetects whether an extra field or method is defined in the APIdefinition file that is not present in the binary file. Additionally,this step will detect whether an extra field or method is present in thebinary file but not defined in the API definition file. If theattributes are incompatible, an error is indicated.

At 1480, the superclasses and superinterfaces are compared. See, forexample, U.S. Provisional Patent Application filed Nov. 12, 1999 in thename of inventor Judith E. Schwabe, entitled “API RepresentationEnabling Submerged Hierarchy”, Ser. No. 60/165,298 and U.S. ProvisionalPatent Application filed Nov. 15, 1999 in the name of inventor Judith E.Schwabe, entitled “API Representation Enabling Submerged Hierarchy”,Ser. No. 60/165,533. If the set of public superclasses orsuperinterfaces of a class or interfaces, respectively, defined in thebinary file do not correspond to the set in the API definition file, averification error is indicated.

At 1485, the set of public implemented interfaces of a class in thebinary file is compared to the set in the API definition file. If thesets of implemented interfaces do not correspond, a verification erroris indicated.

At 1490, for each exported field in the binary file, the field islocated in the API definition file and the attributes of the field inthe API definition file are compared to the definition in the binaryfile. If the field is not located, a verification error is indicated.The attributes may include by way of example, the name, flags and type.If the attributes are incompatible, a verification error is indicated.

At 1495, for each exported method in the binary file, the method islocated in the API definition file and the attributes of the method inthe API definition file are compared to the definition in the binaryfile. If the method is not found in the API definition file, averification error is indicated. The attributes may include by way ofexample, the name, flags and signature. If the attributes areincompatible, a verification error is indicated.

Turning now to FIG. 19, a flow diagram that illustrates loading alibrary or applet onto a resource-constrained device in accordance withone embodiment of the present invention is presented. At 1500, a programunit such as a library or applet package is received. At 1505, theprogram unit is authenticated. At 1510, a determination is maderegarding whether the program unit references one or more other programunits. If the program unit references one or more other program units,at 1515, the version of the API definition file used during verificationis checked to determine whether it is compatible with the version of thereferenced binary file resident on the resource-constrained device. Ifthe versions are not compatible, an error is indicated. At 1520, theprogram unit is loaded or otherwise prepared for execution when theversion of the API definition file used during verification iscompatible with the version of the referenced binary resident on theresource-constrained device.

The invention as described thus far has pertained to scenarios where theversion of a referenced binary file is the same version as itscorresponding API definition file. As discussed previously, both theJava™ specification and the Java Card™ specification define behaviorwhere the version of a referenced binary file is a newer version thanthe one used during preparation of the referencing binary file.Furthermore, these specifications define changes that can be made whenrevising a binary file that result in the new version being backwardcompatible with the previous version. When a newer version is backwardcompatible with an older version it is said to be binary compatible.

Binary compatible changes to a referenced binary file are undetectableto a referencing binary file. The updated referenced binary file isrequired to contain all of the elements of the API definition file ofthe original binary file. Accordingly, a referencing binary file isprovided with a superset of the element in original API of thereferenced binary file, and therefore all of the elements it referencesare guaranteed to be present. A referencing binary file may besuccessfully linked with, verified with and executed with any binarycompatible revision of the original target referenced binary file. Thus,it is valid in both Java™ and Java Card™ technology to prepare a binaryfile using an old version of a referenced binary file and then laterlink, verify and execute with a new, binary compatible version of thereferenced binary file.

According to one embodiment of the present invention, an additionalverification step is performed on a resource-rich device to confirmwhether or not a revision of a binary file is binary (backward)compatible with an earlier version. This additional step provides thefunctionality required to assert that a referencing binary file and abinary compatible revision of a referenced binary file constitute averified set. The details of this verification step are described inFIGS. 20A through 20D.

Those of ordinary skill in the art will recognize that other versioningschemes can also be used to provide binary compatibility information aswell.

Turning now to FIG. 20A, a block diagram that illustrates verificationusing API definition files of backward compatible revisions inaccordance with one embodiment of the present invention is presented.The example illustrated in FIG. 20A includes an applet A1 thatreferences library L0. Library L0 has two versions, 1.0 and 1.1. Eachversion of library L0 has been previously converted to a binary file andan API definition file. The A1 binary file 1530 was initially verifiedagainst L0 version 1.0. The precondition for this verification isverifying the L0 API definition file version 1.0 (1535) with the L0binary file version 1.0 (1540). As described in FIG. 13A, theseverification steps indicate that A1 binary file (1530) is verified withL0 binary file version 1.0 (1540).

Library L0 version 1.0 was subsequently changed to create L0 version1.1. According to one embodiment of the present invention verificationof the A1 binary file (1530) with the L0 version 1.1 binary file (1550)is established by verifying that L0 API definition file version 1.1(1545) is backward compatible with L0 API definition file version 1.0(1535) and by verifying that L0 API definition file version 1.1 (1545)verifies with L0 binary file version 1.1 (1550). Hence, a modifiedreferenced library does not require verification of a referencing appletwith the API definition file of the modified referenced library when itcan be shown that the API definition file of the modified referencedlibrary is backward compatible with the original referenced library andwhen the API definition file of the modified referenced library verifieswith the binary file of the modified referenced library.

The verification steps shown in FIG. 20A indicate that A1 binary file(1530) is verified with L0 binary file version 1.1 (1540).

Turning now to FIG. 20B, a block diagram that illustrates verificationusing API definition files of backward compatible revisions inaccordance with one embodiment of the present invention is presented.FIG. 20B illustrates the case where a binary compatible version of alibrary has been previously installed on a resource-constrained device.The referencing binary file, A1 (1550), is prepared and verified usingan earlier version of the referenced API definition file. The L0 binaryfile version 1.1 (1560) was previously verified with the L0 APIdefinition file version 1.1 (1555). Next, the previously verified API(L0 API definition file version 1.1 (1555)) is verified to be backwardcompatible with the earlier version (L0 API definition file version 1.0(1560))). Next, the A1 binary file (1550) is verified using the APIdefinition files of the referenced library (L0 API definition fileversion 1.0 (1560)) and the A1 binary file (1550) is installed on theresource-constrained device 1565. A loader 1570 on theresource-constrained device 1565 verifies that the API definition fileused during verification is compatible with the referenced binary file.The resulting content of the resource-constrained device 1565 is averified set of binary files: A1 binary file (1550) and L0 binary fileversion 1.1 (1560).

Turning now to FIG. 20C, a flow diagram that illustrates verifyingversions using API definition files in accordance with one embodiment ofthe present invention is presented. At 1600, the old version of thepackage API definition file is received. At 1605, the new version of thepackage API definition file is received. At 1610, a determination ismade regarding whether the version of the new package indicates backwardcompatibility with the version of the old package. In Java Card™technology, for example, this determination is made by comparing majorand minor version numbers. If the new version is backward compatible, at1615, the content of the new API definition file is verified forbackward compatibility with the content of the old API definition file.

Turning now to FIG. 20D, a flow diagram that illustrates verifying thatthe content of a new API definition file is backward compatible with thecontent of an old API definition file in accordance with one embodimentof the present invention is presented. At 1620 and 1625, the old packageAPI definition file and the new API package definition are received.

At 1630, the package attributes are compared. The attributes may includethe package name and the number of classes and interfaces. If the set ofclasses and interfaces defined in the old API definition file is notfound in the new API definition file, a verification error is indicated.

Several checks are performed for each class and interface in the oldpackage. At 1635, the class and interface attributes are compared to theattributes of the same class or interface in the new package. Theattributes may include the name, flags, number of fields and number ofmethods. If the sets of fields and methods defined in a class orinterface in the old API definition file are not found in thecorresponding class or interface in the new API definition file, averification error is indicated. If any other the attributes of a classor interface are not binary compatible, a verification error isindicated.

At 1640, the superclasses and superinterfaces of the class or interfaceare compared to the same in the new package. If the sets of superclassesor superinterfaces of a class or interface, respectively, are not binarycompatible, a verification error is indicated.

At 1645, the implemented interfaces of a class are compared to the samein the new package. If the sets of implemented interfaces of a class arenot binary compatible, a verification error is indicated.

At 1650, for each field in the old package, the attributes are comparedto the same field in the new package. The attributes may include thename, flags and type. If the attributes of a field are not binarycompatible, a verification error is indicated.

At 1655, for each method in the old package, the attributes are comparedto the same method in the new package. The attributes may include thename, flags and signature. If the attributes of a method are not binarycompatible, a verification error is indicated.

The list of binary compatibility checks performed is not intended to bean exhaustive list. Further details regarding binary compatibility maybe found in the Java™ Language Specification and the Java Card™ VirtualMachine Specification.

According to embodiments of the present invention, program modules areverified on a resource-rich device prior to an installation on aresource-constrained device such as a smart card. FIGS. 21A to 21Dillustrate different embodiments in which verification is performed.

According to one embodiment of the present invention, program modulesare optionally verified by a card manufacturer, a card issuer and anapplet or library provider. Verification may performed by anycombination of the above parties. Referring to FIG. 21A, a manufacturerensures that the initial content is verified and prepares a device withthat initial content (1660) before shipping the device to an issuer. Theinitial modules may be verified either by the manufacturer, the appletor library provider (1675), or both. The issuer receives the device fromthe manufacturer, optionally installs additional modules, disablesfurther installations and distributes the device (1665) to an end user1670. If additional modules are installed, the issuer ensures that theyare verified before installation. The issuer, applet or libraryprovider, or both may perform verification.

Turning now to FIG. 21B, according to another embodiment of the presentinvention, program modules are optionally verified by a cardmanufacturer (1690), a card issuer (1705), an applet provider (1700) anda trusted post-issuance installer (1695). Verification may be performedby any combination of the above parties, but must result in each modulebeing verified before it is installed on a device. Referring to FIG.21B, post-issuance installations by a trusted installer (1695) areallowed. Verification is optionally performed by the applet or libraryprovider (1700) before shipping. Verification is also optionallyperformed by the manufacturer (1690), the issuer (1705) and thepost-issuance installer (1695) before the additional content isinstalled on the device.

In FIG. 21B, the post-issuance installer is a trusted installer (1695).A trusted installer (1695) is an installer that has an agreement withthe issuer, governing the post-issuance updates of cards. In contrast,an untrusted installer has no such agreement with the installer. When anissuer issues cards without disabling subsequent installations, anuntrusted and possibly malevolent post-issuance installer couldpotentially add program modules to a card. Such unauthorized additionsmay corrupt the existing program modules or compromise them in otherways, causing the program to either execute erroneously or not executeat all.

According to another embodiment of the present invention, verificationof program modules is performed in a system that allows post-issuanceinstallations by an untrusted installer. Referring to FIG. 21C, notethat FIG. 21C is the same as FIG. 21B, except that the post-issuanceinstaller (1725) is untrusted. Preferably, the verifier in this caseresides on a terminal device or another device not under the control ofthe untrusted installer (1725).

According to another embodiment of the present invention, verificationof program modules is performed in a system that allows post-issuanceinstallations by an untrusted installer. Furthermore, this embodimentperforms binary compatibility checks as part of the verification.Referring to FIG. 21D, note that FIG. 21D is the same as FIG. 21C,except that each party that performs verification includes binarycompatibility checks in the verification process. Those of ordinaryskill in the art will recognize that verification that entails binarycompatibility checks can also be applied to the scenarios shown in FIGS.21A and 21B.

The above embodiments differ in the entities that are involved in thepreparation of a card for an individual user. The above embodiments alsodiffer regarding whether post-issuance installation is enabled. However,the details of verification process are equivalent, regardless of theentity performing the verification.

According to one embodiment of the present invention, the manufacturer,issuer and trusted post-issuance installer consider the applet orlibrary to have been received from a potentially hostile environment.The verifier is run with the applet or library before installation. Themanufacturer, issuer and trusted post-issuance installer make adetermination regarding whether their environments are secure. If theenvironments are secure, the scenario depicted in either FIG. 11A(verifier on resource-rich device) or FIG. 11B (verifier on terminal) isused. If the environments are not secure, the scenario depicted in FIG.11B (verifier on terminal) is used.

Preferably, the untrusted post-issuance installation operates in thescenario depicted in FIG. 11B (verifier on terminal).

In the scenario depicted by FIG. 11A (verifier on resource-rich device),the content provider preferably runs the verifier before shipping (usingFIG. 11A), thus confirming that the binary file was not corrupted whenit was prepared or stored in the applet/package provider's environment,and ensuring that the applet/package provider is not shipping a hostilebinary file to the manufacture, issuer, trusted post-issuance installer,or untrusted post-issuance installer.

According to one embodiment of the present invention, verificationincludes binary compatibility checks. Preferably, the manufacturer andissuer confirm that the updated resource-constrained device is binarycompatible with the previous version(s). This prevents an older programunit from being placed into an invalid context when installed.

According to a preferred embodiment, programmatic content is installedin a secure environment. Once a verified binary file has been installed,the smart card's programmatic content is not altered by an unauthorizedentity. Therefore, once a verified binary file is installed in thissecure environment, the binary file's verification status is unchangedbetween subsequent executions. In other words, the binary file need notbe re-verified before each execution.

Although the present invention has been illustrated with respect to asmart card implementation, the invention applies to other devices with asmall footprint such as devices that are relatively restricted orlimited in memory or in computing power or speed. Suchresource-constrained devices may include boundary scan devices, fieldprogrammable devices, pagers and cellular phones among many others.

The present invention also relates to apparatus for performing theseoperations. This apparatus may be specially constructed for the requiredpurpose or it may comprise a general-purpose computer as selectivelyactivated or reconfigured by a computer program stored in the computer.The procedures presented herein are not inherently related to aparticular computer or other apparatus. Various general-purpose machinesmay be used with programs written in accordance with the teachingsherein, or it may prove more convenient to construct more specializedapparatus to perform the required process. The required structure for avariety of these machines will appear from the description given.

While the Java™ programming language and platform are suitable for theinvention, any language or platform having certain characteristics wouldbe well suited for implementing the invention. These characteristicsinclude type safety, pointer safety, object-oriented, dynamicallylinked, and virtual machine based. Not all of these characteristics needto be present in a particular implementation. In some embodiments,languages or platforms lacking one or more of these characteristics maybe utilized. Also, although the invention has been illustrated showingobject-by-object security, other approaches, such as class-by-classsecurity, could be utilized.

Additionally, while embodiments of the present invention have beenillustrated using applets, those of ordinary skill in the art willrecognize that the invention may be applied to stand-alone applicationprograms.

The system of the present invention may be implemented in hardware or ina computer program. Each such computer program can be stored on astorage medium or device (e.g., CD-ROM, hard disk or magnetic diskette)that is readable by a general or special purpose programmable computerfor configuring and operating the computer when the storage mediumdevice is read by the computer to perform the procedures is described.The system may also be implemented as a computer-readable storagemedium, configured with a computer program, where the storage medium soconfigured causes a computer to operate in a specific and predefinedmanner.

The program is here, and generally, conceived to be a self-consistentsequence of steps leading to a desired result. These steps are thoserequiring physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike. It should be noted, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities.

Thus, a novel system and method for program verification using APIdefinition files has been described. While embodiments and applicationsof this invention have been shown and described, it would be apparent tothose skilled in the art having the benefit of this disclosure that manymore modifications than mentioned above are possible without departingfrom the inventive concepts herein. The invention, therefore, is not tobe restricted except in the spirit of the appended claims.

1-77. (canceled)
 78. A method comprising: receiving content verified byat least one content provider, wherein said content includes: at leastone program unit comprising an Application Programming Interface (API)definition file and an implementation wherein said API definition filedefines items in a program unit associated with said API definition filewherein said items are made accessible to one or more other programunits; and said implementation includes executable code corresponding tosaid API definition file wherein said executable code includes typespecific instructions and data; and installing said content on aresource-constrained device.
 79. The method of claim 78 furthercomprising: disabling subsequent installation of content on saidresource-constrained device.
 80. The method of claim 78 wherein saidcontent provider comprises at least an applet provider.
 81. The methodof claim 78 wherein said content provider comprises at least a devicemanufacturer.
 82. The method of claim 78 wherein said content providercomprises at least a device issuer.
 83. The method of claim 78 whereinsaid content provider comprises at least a trusted post-issuanceinstaller.
 84. The method of claim 83 further comprising: allowingpost-issuance installation of verified content on saidresource-constrained device by said trusted post-issuance installer,said post-installation occurring after issuance of said resourceconstrained device.
 85. The method of claim 84 wherein said verifiedcontent in said post-issuance installation comprises: a new program unitverified by said trusted post-issuance installer; and said post-issuanceinstallation is performed by said trusted post-issuance installer. 86.The method of claim 84 wherein post-issuance verification of saidcontent is performed on a resource-rich device.
 87. The method of claim84 wherein post-issuance verification is performed on a terminal device.88. The method of claim 83 wherein said content provider comprises saidtrusted post-issuance installer and at least one other content providerselected from a group consisting of an applet provider, a devicemanufacturer, and a device issuer.
 89. The method of claim 1 whereinsaid content provider comprises at least an untrusted post-issuanceinstaller.
 90. The method of claim 89 further comprising: allowingpost-issuance installation of verified content on saidresource-constrained device by said untrusted post-issuance installer,said post-installation occurring after issuance of said resourceconstrained device.
 91. The method of claim 90 wherein said verifiedcontent in said post-issuance installation comprises: a new program unitverified by said untrusted post-issuance installer; and saidpost-issuance installation is performed by said untrusted post-issuanceinstaller.
 92. The method of claim 90 wherein post-issuance verificationof said content is performed on a resource-rich device.
 93. The methodof claim 90 wherein post-issuance verification is performed on aterminal device.
 94. The method of claim 89 wherein said contentprovider comprises said untrusted post-issuance installer and at leastone other content provider selected from a group consisting of an appletprovider, a device manufacturer, and a device issuer.
 95. A programstorage device readable by a machine, embodying a program ofinstructions executable by the machine to perform program verification,comprising: receiving content verified by at least one content provider,wherein said content includes: at least one program unit comprising anApplication Programming Interface (API) definition file and animplementation wherein said API definition file defines items in aprogram unit associated with said API definition file wherein said itemsare made accessible to one or more other program units; and saidimplementation includes executable code corresponding to said APIdefinition file wherein said executable code includes type specificinstructions and data; and installing said content on aresource-constrained device.
 96. The program storage device of claim 95further comprising: disabling subsequent installation of content on saidresource-constrained device.
 97. A system for executing a softwareapplication, the system comprising: a computing system that generatesexecutable code, comprising means for receiving content verified by atleast one content provider, said content including at least one programunit, each program unit comprising an Application Programming Interface(API) definition file and an implementation, each API definition filedefining items in its associated program unit that are made accessibleto one or more other program units, each implementation includingexecutable code corresponding to said API definition file, saidexecutable code including type specific instructions and data; and meansfor installing said content on a resource-constrained device;
 98. Aresource-constrained device comprising: memory for providing contentverified by at least one content provider, said content including atleast one program unit, each program unit comprising an ApplicationProgramming Interface (API) definition file and an implementation, eachAPI definition file defining items in its associated program unit thatare made accessible to one or more other program units, eachimplementation including executable code corresponding to said APIdefinition file, said executable code including type specificinstructions and data; and a virtual machine that is capable ofexecuting instructions included within content.
 99. Theresource-constrained device of claim 98 wherein saidresource-constrained device comprises a smart card.
 100. Theresource-constrained device of claim 98 further comprising: an installerdevice for installation of said content on said resource-constraineddevice.
 101. The resource-constrained device of claim 100 furthercomprising installation of additional content by a post-issuanceinstaller after said resource-constrained device is issued to an enduser